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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within TC SCP and may change following formal 
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with 
an identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

early working draft; 

1 presented to TC SCP for information; 

2 presented to TC SCP for approval; 

3 or greater indicates TC SCP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present document specifies the requirements for Release 7 of the TC SCP. 
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1 Scope 

The present document specifies the additional requirements for Release 7 of the TC SCP with respect to earlier releases. 
The present document covers all the Stage 1 requirements which are not covered by other TC SCP stage 1 documents. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to an TC SCP document, a 
non-specific reference implicitly refers to the latest version of that document in the same Release as the 
present document. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ETSI TS 102 221: "Smart cards; UICC-Terminal interface; Physical and logical characteristics". 

[2] ETSI TS 102 223: "Smart cai'ds; Card AppHcation Toolkit (CAT) (Release 6)". 

[3] 3GPP TS 22.038: "3rd Generation Partnership Project; Technical Specification Group Services 

and System Aspects; USIM Application Toolkit (US AT); Service description; Stage 1; 
(Release?)". 

[4] ETSI TS 151 Oil: "Digital cellular telecommunications system (Phase 2+); Specification of the 

Subscriber Identity Module - Mobile Equipment (SIM -ME) interface (3GPP TS 51.01 1)". 

[5] ETSI TS 13 1 102: "Universal Mobile Telecommunications System (UMTS); Characteristics of the 

USIM application (3GPP TS 31.102 version 6.11.0 Release 6)". 

[6] ISO/lEC 7816-4: "Identification cards - Integrated circuit cards - Part 4: Organization, security and 

commands for interchange". 

[7] Trusted Computing Group (2003): "TPM Main Part 1 Design Principles" specification 

version 1.2". 

NOTE: Available at https://www.trustedcomputinggroup.org/downloads/tpmwg- 
mainrev62 Parti Design Principles.pdf . 
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3 Definitions, symbols, abbreviations and coding 

conventions 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

ME/TE owner: entity having the right to configure or administrate a CAD and/or remote terminal 

terminal: entity with which the Smart Card can establish a secure channel 

EXAMPLE 1: Card Acceptance Device such as a mobile handset i.e. in the case of a wired Smart Card to 
terminal (such as PDA or handset) communication; 

EXAMPLE 2: A Remote Terminal is a terminal communicating to a CAD, which can access the UICC resources, 
for example a PC connect over a local link to handset. 

NOTE: In the present document a distinction will be made between a CAD and a Remote Terminal only where 
applicable, in case this distinction is not relevant the generic term terminal will be used. 

terminal end point: point for terminating the secure channel from the UICC point of view, which could be a Mobile 
Terminal or a Remote Terminal 

EXAMPLE: A remote terminal can be a Set-top box, a PC, or even a Bluetooth earpiece connected to a Mobile 
Terminal. 



User Equipment 
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applications 
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Remote 
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Figure 1 : Possible secure channels with a UICC 

trusted device: device which is not infected by malevolent code, whether because it is compliant to the requirements 
defined in TCG [7] or because the user/owner/administrator guarantees device integrity by giving verifiable evidence 

NOTE: A more exact definition is out of scope of SCP. 

3.2 Symbols 

Void. 
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3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ADF Application Dedicated File 

CAD Card Acceptance Device 

CAT Card Application Toolkit 

CEK Content Encryption Key 

DF Dedicated File 

DM Device Management 

DRM Digital Rights Management 

DRM_UA Digital Rights Management User Agent 

EAP Extensible Authentication Protocol 

EF Elementary File 

GPRS General Packet Radio Service 

HTTP HyperText Transfer Protocol 

HTTPS Secure HyperText Transfer Protocol 

IMS IP Multimedia Services 

IP Internet Protocol 

ISIM IMS SIM 

JSR Java Specification Request 

ME Mobile Equipment 

MNO Mobile Network Operator 

MO (Device) Management Object 

MT Mobile Termination 

NUT New UICC-Terminal 

OMA Open Mobile Alliance 

OTA Over The Air 

PIN Personal Identification Number 

POP Post Office Protocol 

RFID Radio Frequency Identification 

RO Rights Object 

SC Smart Card 

sews Smart Card Web Server 

SMTP Simple Mail Transfer Protocol 

TCG Trusted Computing Group 

TLS Transport Layer Security 

TMP Trusted Media Player 

UA (Digital Rights Management) User Agent 

UE User Equipment 

UMTS Universal Mobile Telecommunications System 

URL Uniform Resource Locator 

USIM Universal Subscriber Identity Module 

USSM UICC Security Service Module 

WIM Wireless Identity Module 



3.4 Coding Conventions 



Void. 



Requirements 



The present document specifies: 

• run time environment timing constraints; 

• launch application command; 

• mapped file support on the UICC; 
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extension of logical channels; 

secure channel to secure local terminal interfaces; 

authenticate command longer than 255 bytes; 

CAT mechanisms to indicate the bearer connection status; 

New UICC-Terminal (NUT) interface; 

Smart Card Web Server running in UICC; 

API for applications registered to a Smart Card Web Server; 

specific UICC environmental conditions; 

introduction of high density memory technology in UICC; 

power supply indication mechanism. 



4.1 Run time environment timing constraints 

4.1.1 Abstract (informative) 

SCP specifications up to Release 6 do not put any restrictions to the run time behaviour of Smart Card applications on 
the CAT layer and on the application layer. However, an example for a situation which requires a defined runtime 
behaviour of the UICC is given in a note in Release 6 of TS 102 223 [2]: The maximum work time of applications 
before sending a MORE TIME proactive command to the terminal should not exceed a certain amount of time. This 
remark is made in the context of the network authentication command and it is not normative. To avoid future problems 
due to this undefined behaviour, the requirements in this clause aim at providing the infrastructure needed to achieve 
standardized behaviour in situations like those described above from Release 7 onwards. 

4.1.2 Background (informative) 



4.1.2.1 



Use case - Network authentication 



An application may not block a UICC with a USIM application longer than a well defined period of time in order to be 
able to process network authentication commands within a time limit which is a network parameter 
(TS 102 223 [2] Release 6). 



4.1.3 Requirements 



Identifier 



Requirement 



REQ-7-01-01-01 



The UICC shall provide a mechanism to assign a maximum work time to an application. The time 
value might be network specific. 



REQ-7-01-01-02 



The UICC shall not be blocked by an application for an amount of time exceeding the configured 
maximum work time. 



REQ-7-01-01-03 



In addition, the application itself shall be able to assign its own maximum work time value. 



REQ-7-01-01-04 



The application shall be suspended by the run time environment after the work time has expired and 
control shall be given back to run time environment. 



REQ-7-01-01-05 



The run time environment shall return control to the application if no other task with higher priority 
(e.g. network authentication) is pending. 



REQ-7-01-01-06 



The task switch procedure shall be transparent to the application. 



REQ-7-01-01-07 



Any security related to the tasks shall not be weakened by the task switch. 



4.1 .4 Interaction witin existing features (informative) 



(none) 
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4.2 Launch Application command 

4.2.1 Abstract (informative) 

(none) 

4.2.2 Backgrouncd (informative) 

The present document presents a stage 1 requirement and high-level description for the Launch Application feature. 

The requirements are based on an existing requirement in the 3GPP stage 1 specification for toolkit feature TS 22.038 
release 7 [3]. 

As the applications to be launched are mainly independent of the air interface, it is appropriate to standardize this 
feature in TC-SCP rather in 3GPP. This will also make this feature available to other telecom standards. 

Example of terminal applications for such a feature: 

• E-mail: 

CAT can launch an e-mail client on the terminal, providing parameters such as POP server, SMTP 
server, login, password etc. 

• Network management optimization: 

CAT launches an application in the mobile that reports to the USIM; channels and application metrics, 
for network performance monitoring. 

• Proactive synchronization: 

CAT application, triggered by suitable events, may command the start of a data synchronization process 
(e.g. for subscriber related parameters or ME configuration data) that may involve data entities in the UE 
and in a synchronization server. 

• Streaming: 

CAT may launch a streaming client in the terminal to stream a video clip with the address (e.g. URL) 
provided by the CAT. 
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4.2.3 Requirements 



Identifier 



Requirement 



REQ-7-02-01-01 



The CAT shall be able to start a terminal application, providing its name and initial parameters. 



REQ-7-02-01-02 



The terminal shall inform the card (e.g. through events) about the terminal applications that can be 
launched by the CAT, with the corresponding information on the needed parameters to launch each 
terminal application. 



REQ-7-02-01-03 



The informing of the card shall be done after each start of card session and as soon as possible after 
such an eligible application is added to, or removed from the terminal. 



REQ-7-02-01-04 



The user of the terminal shall be able to choose when he should be prompted for the issuance of the 
CAT LAUNCH APPLICATION command. The prompt possibilities shall be: 

• The user is prompted for each application to be launched. 

• The user is prompted for those applications only that the user has selected, the other 
applications are launched without being prompted. 

The user is never prompted, i.e. all the applications are always launched. 



REQ-7-02-01-05 



Once launched, the application may interact with the user or another application, as though the user 
launched the application. 



REO-7-02-01-06 



If the handset is not able to launch the requested application, an error mechanism shall be specified to 
inform the CAT, which shall include a reason code and details as to whether the error is temporary or 
not. 



REO-7-02-01-07 



Each application shall have a unique identifier or reference. 



REO-7-02-01-08 



The format of the identifier shall be standardized. 



REO-7-02-01-09 



There shall be the possibility to provide the application identifier in a standardized way (SCP decides 
for the identifier value), or in a proprietary way (application provider decides for the identifier value). 



REO-7-02-01-10 



An application parameter shall be uniquely identified. 



REO-7-02-01-11 



This requirement shall be implemented as a letter class feature. 



Following are additional information to enhance the general comprehension of the requirements (informative): 
Depending on the terminal application A: 

• The user may have a complete, partial or restricted control over the launched terminal application A. 
This control is not linked to the CAT capacity, but is inherent to the application A itself. 

Examples of eligible applications with complete or partial user control are web browsers, email application, etc. 

• Another ME application B may have a complete, partial or restricted control over the launched terminal 
application A. This control is not linked to the CAT capacity, but is inherent to the application A itself. 

Examples of eligible applications with complete or partial control by an other ME application are synchronization 
application, terminal functionality tuning, etc. 

4.2.4 Interaction witin existing features (informative) 

The release 7 Launch Application feature may be used to extend the LAUNCH BROWSER command in specific cases 
where it procures an advantage. 

Other pre-release 7 features should not be impacted. 

4.3 Mapped file support on the UICC 
4.3.1 Abstract (informative) 

(none) 
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4.3.2 Background (informative) 



When comparing the file structure of a SIM in TS 151011 [4] with that of a USIM in 3G TS 131 102 [5] it appears that 
many EFs not only have the same name and file identifier (although under different DFs) but are entirely equal by size 
and content parameters. This generally allows, for memory efficient implementation, to perform file mapping between 
SIM and USIM files as these files can be shared by both applications, i.e. necessary storage capacity is only required 
once. 

The same is true concerning the mapping of files between multiple USIMs if the UICC is intended to be used by a 
single user, i.e. all user relevant files (that can be updated by the user) could be mapped. 

This is why it seems necessary to standardize the mechanism to map these files. 



4.3.3 Requirements 



Identifier 



Requirement 



REQ-7-03-01-01 



It shall be possible to map the content of EFs that are identical by type, size and content 
(i.e. the necessary storage capacity is only required once) at personalization or "over the air" 



REQ-7-03-01-02 



It shall be possible to setup a security rule to prevent a file from being mapped and thus prevent any 
illicit access to an existing file. 



REQ-7-03-01-03 



The fact that an EF is mapped with another EF shall not restrict the operations allowed on the file 

i.e. the file can be deleted, resized, updated, etc. 

EXAMPLE: 

Filel, File2 and File3 are mapped. 

When Filel is updated, the content of File2 and File3 is changed accordingly. This Is obvious because 

they share the same storage. 

It is possible to delete any of these 3 files in any order for example first delete Filel and after File3, the 

content of File2 remains unchanged.. After, when deleting the third file i.e. File2, the resources held by 

the file shall be released and the memory used by this file shall be set to the logical erased state 



REQ-7-03-01-04 



It shall be possible to have different security attributes for files that are mapped. 



REQ-7-03-01-05 



It shall be possible to have different life cycles for files that are mapped. 



4.3.4 Interaction witin existing features (informative) 

(none) 

4.4 Extension of logical channels 

4.4.1 Abstract (informative) 

TS 102 221 [1] currently specifies up to 3 logical channels in addition to the basic logical channel 0. It means that only 
four logical channels are currently specified. 

4.4.2 Background (informative) 



4.4.2.1 



Typical problem situation 



A situation can be that a UICC has an USIM application, an ISIM (or several) application, a WIM application, an 
application (or several) using the JSR 177 communication capabilities and a banking application, each of these 
applications use a different logical channel. If there are only 4 logical channels this is not possible. 

In the same way a file (EF, DF, ADF) can be accessed using different logical channels at the same time, currently it is 
limited to 4 logical channels. 

In the latest ISO/IEC 7816-4 [6] specification's revision, 16 additional channels have been added. This allows better 
flexibility when several applications run simultaneously. 
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4.4.2.2 Possible problem solution 

The best solution is to extend the number of the logical channels, in line with ISO/IEC 7816-4 [6]. 

4.4.2.3 Use cases 

4.4.2.3.1 Use case - JSR 1 77 applications 

It is possible to have multiple applications running on the terminal talking to the Smart Card at the same time. For 
example multiple Java applications using JSR 177. 

4.4.2.3.2 Use case - PC connection 

A UICC connected to a PC may need to open multiple secured connections to different entities through different logical 
channels. 

4.4.3 Requirements 

4.4.3.1 General Requirements 



Identifier 



Requirement 



REQ-7-04-01-01 



An optional mechanism sliall be introduced that allows the extension of the number of logical channels 
available in addition to the basic channel (i.e. channel 0) and to the three already possible additional 
channels. 



REQ-7-04-01-02 



The mechanism introduced shall be ISO/IEC 7816-4 [6] compliant. 



4.4.3.2 Backward compatibility requirements 



Identifier 



Requirement 



REQ-7-04-02-01 



A release 7 UICC supporting extended channels shall not prevent a pre release 7 terminal to use the 
release 6 logical channel functionality. 



REQ-7-04-02-02 



A release 7 terminal supporting extended channels shall not prevent a pre release 7 UICC to use the 
release 6 logical channel functionality. 



4.4.4 Interaction with existing features (informative) 

(none) 

4.5 Secure channel to secure local terminal interfaces 
4.5.1 Abstract (informative) 

This clause defines requirements for a generic solution of a secure channel between the UICC and an end point 
terminal. Several applications will be able to rely on this generic solution to offer an end to end security. 

• Providing mutual authentication between a UICC and a terminal end point. 

• Providing integrity and confidentiality (encryption) protection of the interface between a UICC and a terminal 
end point. 

The use cases in this clause will justify the need of a secure channel between a UICC and a terminal; it also lists the 
requirements that this secure channel shall fulfil to address all the use cases described herein. 

Standardization efforts have been undergone and are at present being made to define secure channels between 
communicating apphcations running on distant platforms. 
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4.5.2 Background (informative) 



System security can be obtained only if end-to-end protection is achieved. For Smart Card to terminal communication, 
this involves: 

• Secure end on the Smart Card side. This is true by assumption; the Smart Card is a tamper resistant device. 

• Secure end on the terminal side. This is attainable when trusted devices are employed. For example TCG [7] is 
specifying trusted device features and architectures. 

• Secure communication between end devices, that is, the Smart Card and the terminal. 

Multiple scenarios exist in which a secure communication between Smart Card and terminal is necessary. Smart cards 
are resource-limited devices, whose main purpose is to safeguard user identities and secret keys, and to perform 
sensitive cryptographic computations. Smart card use greatly depends on the environment in which they are deployed. 
For example, in banking, user information includes identity, account information, and possibly information on the latest 
transactions made and secret keys used in security functions. The operations allowed encompass card holder 
authentication, automatic transaction registration, transaction non-repudiation. In mobile communications, user 
information includes identity, personal information such as address book, operator related information, and again secret 
keys used in security functions. Functions executed comprehend user authentication, voice encryption, as well as data 
access to user's private information. 

Smart cards were designed to be economic, portable and therefore small and light, yet secure. There are no peripherals 
that allow user direct access, such as a keyboard or a screen: Smart Card access must go through a terminal, and, unless 
the communication is secure end-to-end, this may constitute a security weakness. System security is that of the weakest 
link and, unless strengthened, attackers may target the terminal or the data exchange with the terminal to get round the 
robustness of the tamper resistant device. 

The definition and use of trusted terminals is out of the scope of this submission. In the following clauses we will 
assume the terminal is not infected by malevolent code, whether because it is compliant to the requirements defined in 
TCG [7] or because the user/owner/administrator guarantees device integrity by giving verifiable evidence. 

Multiple use cases justify the need for a Smart Card to terminal secure communication. In the following parts, we cover 
use cases linked with User Interface, Device Management (DM), Digital Right Management (DRM). 

4.5.2.1 Use case - User Interface 

A large amount of information currently flows in GSM/3G network-enabled services that make use of application 
server software and toolkit applications. In most of these services, at least a part of the information flow has no 
protection from eavesdropping or tampering: if we focus on the communication between the UICC and the terminal, the 
information flowing from the card to the terminal, and vice versa, is in plain text [2]. 

In this respect, let us consider the two cases in the following: 



• 



When an application on the UICC requires the user to enter a PIN to access a service, the PIN itself is not 
protected. Therefore, when PIN data is sent from the handset to the UICC, it may be stolen or maliciously 
altered in order to deny the service to the end user. 

• When an application on the UICC sends data to the terminal to display to the user, the data is displayed in 

plain text. Such data may involve, for example, fees to be paid or acceptance of onerous conditions for the use 
of a software/service. If data is tampered with, the user may take upon him/herself a burden different from that 
which has been notified. Issues may be raised on how "legally binding" for a user is the acceptance of 
conditions that have no protection against malicious alteration before submission to the user itself. 

The implementation of a secure channel will allow a secure data exchange between the end user and the service 
provider. 
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4.5.2.2 



Figure 2: User Interfaces 



Use case - UICC as a control point for Device Management 



Device Management, or DM, specified in OMA, intends to provide the protocols and mechanisms allowing to remotely 
achieve management of devices. The Device Management includes: 

• Setting initial configuration information in devices. 

• Subsequent installation and updates of persistent information in devices (firmware update). 

• Retrieval of management information from devices. 

• Processing events and alarms generated by devices. 

In this environment, the Smart Card inserted in the device is expected to play a role at least in the following cases: 

• Dynamic provisioning of the device with up-to-date information. 

• Handling of a part of the security during the update of device firmware (service access controlled by the 
operator, authentication of the origin, ...). 

It means that the Smart Card (SC) shall store DM objects (Management Objects, or MO) accessible by the device 
through the SC to device interface and also manageable by a remote server (through the device). This interface is 
currently not ciphered and DM information will be exchanged without protection. It is easy to imagine some of the 
possible threats occurring during these exchanges: 

when the provisioning data is extracted from the SC by the device, some man-in-the-middle application or 
element could intercept and change some data in order to alter the device configuration or compel the device to 
connect to a fraudulent DM server. The data should therefore be ciphered. 

An unauthorized server or device agent could try to modify the information stored into the SC leading to a later bad 
provisioning of the device. Therefore, only authorized and authenticated device agents or remote servers should be able 
to update or modify or add DM data in the SC. 
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The availability of a secure channel will allow to secure and protect the communications occurring between the device 
DM user agent and the Smart Card. 
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4.5.2.3 



Figure 3: Device IVIanagement 



Use case - DRM and distributed applications 



Digital Rights Management (DRM) is meant to secure media content owned by a service provider; the end-user has a 
limited set of rights to use the content. Usually, media content is supposed to be rendered on any type of compatible 
terminal (e.g. CD audio on any CD player) so that the user can transport his content wherever he wants. Adding security 
should not change this user experience. 

In the event the user is a Mobile Network Operator (MNO) subscriber, Open Mobile Alliance (OMA) DRM specifies a 
model where the rights are bound to a device, not to a user. This implies that when the user needs to change the player 
(i.e., the handset), the rights have to be downloaded onto the new device and the certificates are to be recalculated with 
the new terminal ID. This scheme works well as long as a network connection is available and/or the terminal belongs 
to the same user domain. 

A different scheme is proposed, in order to link the rights to a user rather than to the handset: the Rights Object (RO) 
might be stored in the user's UICC together with part of the DRM user agent. This implies that when the user needs to 
change the player (i.e., the handset), the rights do not have to be downloaded onto the new terminal. This solution has 
the following advantages: 

1) The user can play content in any MT containing a genuine media player (OMA compatible) and accepting the 
UICC. 

2) The user would not require a network connection. This is useful for situations where the user does not have 
network coverage (e.g. underground station; plane). 

3) The MNO stores its RO in a tamper-resistant device, which is under its control (administration via 
OTA platform). 
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This scenario is only possible thanks to the secure channel between a trusted execution environment in the handset and 
the UICC based DRM User Agent (UA) providing the Content Encryption Key (CEK). 

Given that the RO is stored in the UICC, the access to the right can be done directly if the rendering device is the 
mobile handset (CAD) or, indirectly when the rendering device is a remote terminal (e.g., a Set-Top-Box asking for 
rights stored in the UICC). 

UICC based DRM_UA: the DRM user agent stored in the UICC is there to manage the RO associated to a media 
content, by managing the parameters and the decryption key (CEK) and by deciding if a content is authorized to be 
rendered or not. 

The session starts by a mutual authentication between the trusted execution environment in the CAD or remote terminal 
(where the media player is executed) and the UICC based DRM_UA, ending in the opening of a secure channel. Some 
parameters have to be securely sent to the UICC (trusted time, media content id, etc) so that the DRM_UA can handle 
the right accordingly (usage counter decrease, etc) and then securely provide the decrypted CEK to the Trusted Media 
Player (TMP). 

Then the TMP can play the content. 

The session is finished when the content has been rendered and the secure channel is closed. 
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Figure 4: Distributed Application 

4.5.3 Requirements 

This clause describes secure channel's requirements that fit the use cases above. 



4.5.3.1 



End point Requirements 



Identifier 



Requirement 



REQ-7-05-01-01 



The UICC shall be able to establish a secure channel with a terminal (CAD and/or remote terminal). A 
secure channel in this context is defined in the requirements that follow (see use cases in clauses 
4.5.2.1,4.5.2.2,4.5.2.3). 
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4.5.3.2 



Integrity Requirements 



Identifier 



Requirement 



REQ-7-05-02-01 



The secure channel shall allow the integrity of the data to be verified (see use cases in clauses 4.5.2.1 , 
4.5.2.2, 4.5.2.3). 



4.5.3.3 



Confidentiality Requirements 



Identifier 



Requirement 



REQ-7-05-03-01 



Data sent through the secure channel shall be confidentiality-protected depending on the conditions set 

by the policy 

(see use cases in clauses 4.5.2.1 , 4.5.2.2, 4.5.2.3). 



4.5.3.4 



Authentication Requirements 



Identifier 



Requirement 



REQ-7-05-04-01 



It shall be possible for the UICC to authenticate itself to any Terminal end point compliant with this 
feature (see use cases in clauses 4.5.2.1 , 4.5.2.2). 



REQ-7-05-04-02 



It shall be possible for a Terminal end point to authenticate itself to any UICC compliant with this 
feature (see use cases in clauses 4.5.2.1 , 4.5.2.3). 



4.5.3.5 



Audit/Compliance Requirements 



Identifier 



Requirement 



REQ-7-05-05-01 



The terminal end point shall be a trusted device (see clause 4.5.2). 



REQ-7-05-05-02 



Evidence shall be provided on the trust ability level of the device. I.e., assessment of the trust ability 
level shall be possible, for example according to a security certification scheme (see clause 4.5.2). 



4.5.3.6 



Policy Requirements 



Identifier 



Requirement 



REQ-7-05-06-01 



An anti-replay mechanism shall be present and active depending on the policy. 



REQ-7-05-06-02 



It shall be possible to control (e.g. through policy files) what functionality/privileges/access is given to a 
Terminal end point that has authenticated itself to the UICC. 



REQ-7-05-06-03 



It shall be possible for the terminal owner to control (e.g. through policy files) what 
functionality/privileges/access is given to a UICC that has authenticated itself to the terminal. 



4.5.4 Interaction with existing features (informative) 

(none) 

4.6 Authenticate command longer than 255 bytes 
4.6.1 Abstract (informative) 

TS 102 221 [1] specifies only a short length for commands and, therefore large amount of data must be split in several 
commands, each one no longer than 255 bytes. In this case the protocol becomes inefficient. The situation becomes 
critical when an authenticate command must be performed. 
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4.6.2 Background (informative) 



4.6.2.1 



Use case - EAP packet exchange 



A typical situation will be the handling of EAP methods when the EAP packets exceed 255 bytes (e.g. EAP TLS where 
the packet may be up to 65536 bytes). This issue can not be managed today without the definition of a dedicated 
mechanism or the definition of the extended length command. 

Furthermore, the length of the AUTHENTICATE command data is continuously increasing as security needs change. 

4.6.3 Requirements 



4.6.3.1 



General Requirements 



Identifier 


Requirement 


REQ-7-06-01-01 


A mechanism shall allow the UICC and the Terminal to use an authenticate 
command even if the data message is longer than 255 bytes. 



NOTE: The mechanism introduced should be ISO/IEC 7816-4 [6] compliant. 

4.6.3.2 Backward compatibility requirements 



Identifier 



Requirement 



REQ-7-06-02-01 



The authenticate command specified in release 6 and before shall be fully supported by the UICC 
supporting the new mechanism. 



REQ-7-06-02-02 



The support of the new mechanism by the UICC shall be indicated to the Terminal. 



4.6.4 Interaction with existing features (informative) 



(none) 



4.7 



CAT mechanisms to indicate the bearer connection status 



4.7.1 Abstract (informative) 



This requirement introduces a new standardized, reliable mechanism in TS 102 223 [2] to provide the UICC with 
information about the availability of a bearer connection. By means of this new mechanism the UICC knows when it is 
feasible to start a network related proactive command like Send SM or Setup Call. 

Current specifications allow the UICC to use several bearers for communication with servers in the network, e.g. SMS 
and GPRS. The new mechanism shall provide means to indicate and query the status of bearers. 



4.7.2 Background (informative) 



4.7.2.1 



Use case - Availability of network bearers 



There are several applications in the field that want to send SM(s) to a server once a mobile station is switched on. One 
example is an application which checks if the terminal has changed and sends a SMS to a server for Device 
Management purposes. This type of application needs to be reliably informed at the earliest point in time during the 
startup of the mobile station when the SM can be sent successfully, i.e. when the network is available. Currently the 
typical indicator for startup is a Terminal Profile. At the point of time, when the Terminal Profile is sent, some mobiles 
are neither able to handle proactive commands nor is it guaranteed that access to the network is already available. 
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4.7.2.2 Use case - Network connection temporarily lost 

There are situations where the availability and quality of network connections changes often, e.g. when driving through 
tunnels or urban areas in a car or in a train. Mobile services which rely on network connections (e.g. in a smartphone or 
in a PDA equipped with a GSM or UMTS data module) may want to know if a particular network and/or bearer is 
available or which networks and/or bearers are available before establishing connections and transferring data. 

4.7.2.3 Use case - Availability of local bearers 

The current standards allow to use local bearers like Infrared, Bluetooth and WLAN to communicate with office 
equipment in the vicinity. Availability of connections to such equipment may change often when the position of the 
terminal is changed due to the short range of the connection technology. Mobile applications (e.g. in a smartphone or in 
a PDA equipped with a GSM or UMTS data module) may want to use these bearers to connect to the office equipment. 
Having accurate and up-to-date information about the availability of these bearers will simplify the development of 
applications and will improve the user experience. 

4.7.3 Requirements 

4.7.3.1 Requirement 1 -Network Bearer Connection Status 



Identifier 



Requirement 



REQ-7-07-01-01 



For all supported bearers it shall be possible to set up a list of bearers to monitor connection status 



REQ-7-07-01-02 



For all supported bearers it shall be possible to query the status of bearers 



4.7.3.2 Requirement 2 -Local Bearer Connection Status 



Identifier 



Requirement 



REQ-7-07-02-01 



For all supported local bearers, indicated in TERIVIINAL PROFILE, it shall be possible to set up an 
event to monitor connection status 



REQ-7-07-02-02 



For all supported local bearers, indicated in TERIVIINAL PROFILE, it shall be possible to query the 
connection status 



4.7.4 Interaction with existing features (informative) 

(none) 

4.8 New UlCC-Terminal Interface 
4.8.1 Abstract (informative) 

Recently UICC memory size has had a very fast growth, from Kbytes up to Megabytes cards that are almost ready for 
the market today. Certainly this trend will continue in the near future allowing operators to set up a completely new 
services portfolio. 

Next generation services will surely be based on multimedia contents management and the chance to store them inside 
the card, such as MMS storage on a Rel-6 USIM, will be a key feature. Moreover services related to large data transfer 
to and from the card, streaming through the card, personalization and control of external devices will need not only 
large storage capabilities on UICC, but also a fast data access to avoid time latency in service usage granting a better 
level of user experience and higher connectivity to remote service inside or outside the terminal. 

In order to provide these services, some key protocols between UICC and terminal have to be provided. 

Although UICC memory and multimedia capabilities have been going to evolve, current UICC-Terminal interfaces did 
not follow the same evolutionary trend. 
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Taking into account the above mentioned services evolution, current UICC-Terminal interfaces and protocol stacks 
shall be revised and New UICC-Terminal interfaces shall be defined and standardized to manage large-sized cards, 
multimedia Smart Card contents in a faster way and easy connectivity to Internet infrastructure. This new interface shall 
also be backward compatible with the existing interfaces. 

Though the size of storage memory is out of scope of the present document it is felt necessary to warn that memory 
technologies used in UICCs supporting the new interface might be power hungry and therefore a power negotiation 
mechanism should be considered necessary. 

4.8.2 Background (informative) 

Hereafter some use-cases requiring a high-speed dedicated channel between UICC and terminal have been shortly 
described. 

4.8.2.1 Use case - multimedia file management 

As the UICC will be able to store and encrypt/decrypt multimedia files (such as MMS, pictures, MP3 files, video clips) 
customer's usability and Quality User Experience cannot be compromised by a too long wait for the data 
download/upload. For example it could be of interest to associate an image, a sound and eventually a short video to the 
information relative to each contact in order to display all the images and video when accessing the phonebook. 

4.8.2.2 Use case -MMI on UICC 

Large-sized Smart Cards offer the possibility to store card issuer's MMI in the UICC. During initialization process, the 
terminal can detect the type of UICC (which operator, which service providers, which features) and upload the whole 
MMI that the card issuer has defined for its purposes and its services. This operation should be performed only if a New 
UICC is detected by the terminal. This operation shall be performed as fast as customer's experience would not be 
affected. A mechanism to identify the detection of a new UICC should be standardized. 

4.8.2.3 Use case - real-time multimedia data encryption/decryption 

UICC can be used to directly encrypt/decrypt data stream (such as protected voice communications or streamed video 
and music). For example the user should be able to receive multimedia files (e.g. Audio or Video) encrypted using 
rights stored inside the UICC. Both the content and its decryption key should be stored in the UICC and also the 
decryption process could be executed inside the card. The decrypted content could be offered via a streaming protocol 
in order to increase the level of security. In addition the user could also store personal contents in the UICC and send 
them after having protected them through encryption features of the UICC. 

An additional use case requiring very similar capabilities of the interface is the signature of multimedia documents, as it 
is not necessary for the UICC to store the document in order to compute the signature as the document is streamed 
through. 

4.8.2.4 Use case - storage of terminal applications on the UICC 

UICC could be used to store and distribute applications that could be uploaded by the terminal during the initialization 
phase or later. The uploading from the UICC to the terminal (or vice versa) of the applications should happen 
dynamically according to user rights purchased from the operator. This enables efficient management of operator- 
related applications on the terminal and easy deployment of innovative services on the field. 

4.8.2.5 Use case - direct and indirect UICC connection to a PC 

As it is now possible for some devices it should be possible either to insert a UICC directly into a PC laptop or to 
connect the handset to PC laptop in order to download/retrieve some personal data (MMS, pictures, movies, 
applications, etc.) to/from the card in a very quick time but also to easily execute cryptographic operations for accessing 
a secure environment (e.g. PKI for e-commerce). The user should consider the UICC as his trusted storage device, 
ensuring acceptable performances for the targeted use. 

In case of an indirect connection to a PC, the UICC to PC connection should be targeted to be independent from the 
host operating system. Security of the UICC to PC link shall be guaranteed. 
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4.8.2.6 Use case - web server on Smart Card 

UICC can be considered like a web server to which an Internet connection can be estabHshed with a usual Internet 
browser. Such a solution removes the needs of deployment of middleware to interface the functionality of the UICC as 
standard browsers and protocols would be used to access UICC contents and applications. 

Contents will be both stored and dynamically generated on the Smart Card and then transferred to the terminal: the aim 
is to reuse standard graphic features of handsets to allow mobile operators to offer attractive and secure services. A 
quick communication interface between the terminal and the UICC will enhance the web server performances; TCP/IP 
based communication allows internal pages (in the UICC) to be served locally and remotely using standard protocols 
and methods. The operation of insert, delete or modify shall be performed in a very fast way so that customer's 
experience would not be affected. 

Through a web server it will be possible to offer a new range of services such as the possibility to access UICC files 
(e.g. the phonebook, the MP3 and videos list) via a web interface in order to consult or modify them. 

4.8.2.7 Use case - antivirus on UICC 

The usage of the UICC as a storage device or the downloading on it of new applications and services lead to the need of 
antivirus running on the UICC itself, like it happens in a PC environment. The UICC could be able to perform 
auto-scan, to update virus signature or managing user rights and the New UICC-Terminal interface should not affect 
this functionality with a too slow definition files download. 

4.8.2.8 Use case - big phonebook management from the UICC 

Big memory cards will offer the opportunity to provide big phonebooks portability with some additional parameters 
(such as voice activated dialling). The usage of this extra UICC capability should be transparent for the end user thanks 
to a fast exchange of data between the UICC and the terminal. The phonebook data needs to be accessible through each 
of the interfaces of the UICC allowing for administration through either interface. 

4.8.2.9 Use case - reduce personalization time 

As memory of the card increases, more data needs to be written during personalization e.g. prior to card issuance. The 
new interface can be used to personalize the card, e.g. to load Smart Card applications to the UICC in a reasonable time. 

4.8.2.1 Use case - generic TCP/IP connectivity 

Many services can be built using the user's UICC as a trust-enabling device. From that standpoint, it is highly beneficial 
that the New UICC-Terminal interface provides support of TCP/IP as this enables the use and integration of the UICC 
in IP networks as an endpoint. The Smart Card Web Server and the Liberty Alliance use-cases are good candidates for 
the use of such generic TCP/IP connectivity. 
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4.8.3 Requirements 



4.8.3.1 



General Requirements 



Identifier 



Requirement 



REQ-7-08-01-01 



The New UlCC-Terminal (NUT) interface parameters shall be capable of providing 8 IVIbps (net 
interface speed without protocol overheads and re-transmissions) 



REQ-7-08-01-02 



The New UlCC-Terminal interface shall offer technical solutions to evolve to higher speed rates with 
backward compatibility, and be open for future needs (SCP release 8 and onward). 



REQ-7-08-01-03 



A mechanism shall be provided to detect the presence of the NUT interface. 
If no NUT interface is detected, the terminal shall select the ISO/IEC interface. 



REQ-7-08-01-04 



If both the terminal and the card support the NUT interface, the terminal shall select the NUT interface 



REQ-7-08-01-05 



The NUT interface shall provide a proactive mechanism to initiate communication with the terminal 
and/or the network. 



REQ-7-08-01-06 



At least one of the plug-in and mini UICC form factors from a dimensional point of view (width, 
and thickness) shall be able to accommodate the NUT interface. 



height 



REQ-7-08-01-07 



The NUT interface shall be able to support the use of higher level protocols (such as HTTP and 
TCP/IP) in order to provide connectivity to existing infrastructures. 



REQ-7-08-01-08 



After the NUT interface has been activated by the terminal, a higher power consumption can be 
negotiated. 



REQ-7-08-01-09 



An UICC supporting the NUT interface shall support the ISO/IEC interface 



REQ-7-08-01-10 



The NUT interface shall be able to support streaming data 



REQ-7-08-01-11 



It shall be possible to run authentication commands through the NUT interface without affecting the 
existing timing constraints 



REQ-7-08-01-12 



The NUT interface being present on a UICC shall not conflict with the possibility of having an additional 
contact-less connectivity solution 



REQ-7-08-01-13 



The NUT interface being active shall not prevent activity taking place on additional connectivity 
solutions (if present) nor affect responsiveness on this connectivity solution (e.g. swipe mode contact- 
less transactions) 



REQ-7-08-01-14 



The New UlCC-Terminal interface shall not degrade security on the UICC 



REQ-7-08-01-15 



When the NUT interface is used to run only pre-Rel-7-commands, the default UICC power shall not 
exceed what is specified in 102.221 specifications. 



REQ-7-08-01-16 



The introduction of the NUT interface shall not modify the existing form factors (as defined in TS 102 
221 [1]) causing a separate reader to be required. 



REQ-7-08-01-17 



The power consumption of the UICC including the interface when all activities are stopped shall not 
exceed the currently specified value for clock stop mode. 



REQ-7-08-01-18 



To introduce a NUT interface, no new contacts in addition to the 8 contacts specified in ISO/IEC 7816- 
series are to be added to the UICC 



REQ-7-08-01-19 



The use of some of the currently assigned contacts in the SCP specification and non-assigned contacts 
(C4, C6, C8) should be negotiable to allow the limited resources available to be used in the most 
flexible way. 



REQ-7-08-01-20 



There shall be a mechanism to negotiate power consumption of the NUT interface based on the used 
speed. 



REQ-7-08-01-21 



The NUT interface parameters shall offer a predictable scalability mechanism 



REQ-7-08-01-22 



A UICC supporting the NUT interface shall be able to be activated under class C operating conditions / 
supply voltage until adequate operating conditions are negotiated between the UICC and the terminal if 
needed. 



4.8.3.2 



Backward compatibility requirements 



Identifier 



Requirement 



REQ-7-08-02-01 



The New UlCC-Terminal interface shall be backward compatible with the existing interfaces. It shall be 
possible to use a new interface-based UICC with a pre-Release 7 terminal according to pre-Release 7 
specifications. 



REQ-7-08-02-02 



For backward compatibility reasons and in order to preserve the handset's battery time, the UICC shall 
keep its power consumption within the range defined in 102.221 Release 6 unless the New UlCC- 
Terminal interface is activated. 



REQ-7-08-02-03 



The assignment and use of currently non-specified contacts in SCP specifications (C4, C6, C8) is not to 
cause unpredicted operation of the UICC when inserted into an existing terminal, the fact that some 
contacts are left unconnected or connected to a specific level shall not cause operational problems. 
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4.8.4 Interaction with existing features (informative) 

(none) 

4.9 UICC based application acting as a server 

4.9.1 Abstract (informative) 

A connectivity solution to the hosting device is required to enable a client in the terminal to retrieve data from a web 
server running in the UICC. 

4.9.2 Background (informative) 

A Smart Card Web Server can be used to transfer static pages to be displayed to the user. 

A Smart Card Web Server can be used to dynamically generate some pages to be displayed to the user. 

Content stored in the Smart Card Web Server can be updated by a client in the terminal. 

4.9.3 Requirements 



Identifier 



Requirement 



REQ-7-09-01-01 



A connectivity solution shall be provided to enable a client in the terminal request data from a web 
server in the UICC 



REQ-7-09-01-02 



This connectivity solution shall provide a general transport mechanism for HTTP and HTTPS 



REQ-7-09-01-03 



This connectivity solution shall not reduce the security of other UICC applications (e.g. SIIVI, USIM, 
ISIM....) 



REQ-7-09-01-04 



This connectivity solution shall not prevent Card application toolkit sessions from operating 
simultaneously with the Smart Card Web Server sessions 



REQ-7-09-01-05 



This connectivity solution shall be able to handle multiple simultaneous sessions to the UICC 



REQ-7-09-01-06 



This connectivity solution shall allow to transport HTTP requests and responses which are longer than 
255 bytes. 



4.9.4 Interaction with existing features (informative) 

(none) 

4.1 API for applications registered to a Smart Card Web Server 

4.10.1 Abstract (informative) 

A Web Server on the Smart Card (SCWS) receives requests from a client and provides HTML content as a response. 
This content can either be static or dynamic. 

Dynamic content can be created by the web server itself or by special applications in the Smart Card (servlet-like 
applications). In order to extend the functionality of the SCWS it is necessary to load these special applications (which 
create dynamic content on behalf of the web server) to the Smart Card after issuance. 

4.10.2 Background (informative) 

A service provider wants to use the Smart Card of a user as an authentication device. He develops an application, which 
computes the response to a challenge using a key in the application and asks his operator to install it in the Smart Card 
of the user. 

The user browses a page of the service provider and receives a page with a link to the Smart Card Web Server. When 
the user clicks on this link, a request is issued to the SCWS, where the URL contains the name of the application and 
the challenge as a parameter. 
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The Smart Card invokes the application of the service provider, which computes the response to the challenge and 
returns a page to the web server, which is returned to the browser and displayed. This returned page contains a link to 
the service provider, which includes the response to the challenge in the URL. When the user clicks on this link, the 
response is sent within the URL to the service provider. 

4.1 0.2.1 Registration of an application to the SOWS 

When the operator installs the application of the service provider it registers under a given name to the Smart Card Web 
Server. 

4.1 0.2.2 Data exchange between SOWS and application 

When the application is invoked by the SCWS the challenge is passed to the application. 

After the dynamic content is created by the application, it is passed back to the SCWS. The SCWS returns this response 
page as the result of the request. 

4.10.3 Requirements 



Identifier 



Requirement 



REQ-7-10-01-01 



There shall be a mechanism to register and de-register an application to a Smart Card Web Server 



REQ-7-10-01-02 



It shall be possible to perform registration/de-registration of an application separately from Its 
installation/un-installation (not necessarily excluding the possibility for a combined register/install or de- 
register/uninstall mechanism) 



REQ-7-10-01-03 



There shall be a secure mechanism to allow a Smart Card Web Server to invoke a registered 
application 



REQ-7-10-01-04 



There shall be a secure mechanism to allow a Smart Card Web Server to pass parameters to a 
registered application 



REQ-7-10-01-05 



There shall be a secure mechanism to allow a registered application to return data to a Smart Card 
Web Server 



REQ-7-10-01-06 



These mechanisms shall be available in form of an API for Java Card Applets 



4.10.4 Interaction with existing features (informative) 

(none) 

4.1 1 Specific UICC environmental conditions 

4.11.1 Abstract (informative) 

The mobile telecommunication industry is extending its business beyond the existing communication services offered 
by normal handsets. For example, automotive service, machine-to-machine communication and RFID are possible 
services and estimated to become a large market in the near future. For such new business areas, various types of 
mobile terminals are required to be developed for each environment and those terminals are likely to be used at times in 
a harsh environment compared to the normal handset. For a harsh environment such as in cars, machines and outdoors, 
electrical equipment is generally required to have much reliability to conform to its usage environment, which is also 
appUcable to the UICC. 

The use cases and requirements for specific UICC environmental conditions listed below are optional features of the 
UICC. 

4.1 1 .2 Background (informative) 

This clause lists use cases relevant to specific UICC environmental conditions. 
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4.1 1 .2.1 Use case - Automotive service 

Mobile communication integration with automotive service will be expected to become a large market in the future. A 
mobile terminal embedded in the car navigation system can offer various services such as interactive information 
(traffic and shop, etc) services, remote car diagnosis services, automatic emergency reporting and remote navigation 
using video call. 

4.1 1 .2.2 Use case - Remote monitoring camera 

Remote images can be monitored in real-time by setting a camera with a mobile terminal at a certain location. Examples 
of these types of demands are monitoring of children in the nursery school, pets left at home, monitoring of mountains, 
rivers and coastal regions for disasters such as typhoon, flood, volcano and earthquake. In some cases, these terminals 
are placed outdoor and exposed to the open air conditions. 

4.1 1 .2.3 Use case - Remote stock monitoring for vending machines 

The mobile terminal is embedded in a vending machine, which can communicate with the monitoring server. When 
stocks become low, the machine automatically conveys this to the server, so that the staff can replenish the product in 
the vending machine. The terminal has to be able to work in outdoor conditions. 

4.1 1 .2.4 Use case - Online electronic advertising board 

Advertising contents can be automatically managed and updated by a delivery server using a mobile communication 
network. The electronic board can be set anywhere, e.g. on top of the buildings, on the street or in the station. 

4.1 1 .3 Considerations (informative) 

The UICC is the key component in the mobile terminal. If it does not operate due to temperature or ambient harsh 
environment, mobile communication service itself can not be offered. Therefore the reliability on environmental 
conditions should be taken into consideration. 

4.11.4 Requirements 

4.1 1 .4.1 Requirement 1 : Temperature range 



Identifier 



Requirement 



REQ-7-11-01-01 



The temperature range for specific environmental conditions shall be classified according to its range. 



REQ-7-11-01-02 



The temperature class A shall be defined as the temperature range for card operation specified in TS 
102 221 [1]. 



REQ-7-11-01-03 



The temperature class B for full UICC operational use and storage shall be between -40 °C and +85 °C. 



REQ-7-11-01-04 



The temperature class C for full UICC operational use and storage shall be between -40 °C and 
+105°C. 



REQ-7-11-01-05 



The temperature class D for full UICC operational use and storage shall be between -40 °C and 
+125°C. 



REQ-7-11-01-06 



Temperature classes other than class A shall be optional, allowing manufacturers to choose the class 
according to the application. 



REQ-7-11-01-07 



It shall be possible for the UICC to indicate its temperature class to the terminal. If there is no indication 
of temperature class, that shall be interpreted as temperature class A. 



4.1 1 .4.2 Requirement 2: Humidity condition 



Identifier 



Requirement 



REQ-7-11 -02-01 



It shall be possible to associate an optional additional humidity condition with the UICC. 



REQ-7-11 -02-02 



The optional humidity condition shall be associated with each temperature class separately. It shall 

allow operational usage and storage of the UICC at 

90 - 95%RH humidity throughout the temperature range. 
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4.1 1 .5 Interaction with existing features (informative) 

(none) 

4.12 Introduction of high density memory technology in UICC 
4.12.1 Abstract (informative) 

The addition of a high-speed interface to the card will enable proper user-experience regarding any service dealing with 
a large amount of data stored on the card. Therefore, such large memory cards will appear and they will need to be 
manufactured using available memory technology. 

There is a strong expectation from the handset manufacturers to use voltage class "C" in the future. 

Today, these memory technologies do not allow for compliance with existing UICC power constraints (both current and 
class "C" voltage). 

In order to be able to use such cards, additional electrical conditions may be needed. 



4.12.2 BackgrouncJ (informative) 



4.1 2.2.1 Use case - Enhanced UICC features 

The card provides the subscriber with a larger amount of memory, allowing for enhanced UICC features: 

• Addition of new fields in the phonebook. 

• Larger amount of phonebook entries. 

• Storage of large files such as multimedia files, messages. 

• Other personal information. 



4.12.3 Requirements 



Identifier 



Requirement 



REQ-7-12-01-01 



A mechanism shall be defined or adapted if necessary so that the UICC is able to indicate its electrical 
needs (current and voltage) to the terminal. 



REQ-7-12-01-02 



A mechanism shall be defined or adapted if necessary so that the UICC is informed of the capability of 
the terminal to support its electrical needs (current and voltage) 



REQ-7-12-01-03 



The mechanisms defined in REQ-7-12-01-01 and REQ-7-12-01-02 shall be included in the initialization 
of the UICC 



REQ-7-12-01-04 



For backward compatibility, the UICC shall be compliant with pre-Rel-7 features, and in particular with 
the electrical characteristics, if the mechanism defined in REQ-7-12-01-02 is not supported by the 
terminal or if the terminal cannot provide the voltage and/or current values required by the UICC. In this 
last case the UICC functionality based on high density memory shall not be available if it exceeds pre- 
Rel-7 (102.221 R6) voltage and current requirement. 



REQ-7-12-01-05 



In case a new voltage class is introduced the system impact shall be analysed and the impact kept to a 
minimum. 



4.12.4 Interaction with existing features (informative) 



(none) 
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4.13 Power supply indication mechanism 

4.13.1 Abstract (informative) 

Currently TS 102 221 [1] specifies that a UICC application may specify its own maximum power consumption values 
up to a maximum value as specified in the table 6.3. In the same clause it also states that a terminal shall be able to 
supply at least the values of power consumption indicated in the table 6.4. It means that there are terminals in the field 
which supply the power consumption to the UICC in a range from the minimum (see TS 102 221 [1], table 6.4) up to 
the maximum (see TS 102 221 [1], table 6.3). If the terminal is not able to supply the power consumption requested by 
the UICC then the application may not work properly. In order to avoid this problem it is mandatory that the UICC 
application requires a value of power consumption which the mobile is able to supply. The problem is that there is no 
mechanism which informs the UICC application about the maximum value of power consumption the terminal is able 
to supply. 

In the case where the terminal is not able to supply the value of power consumption requested by the UICC application 
it is useful if the UICC application can reduce its power consumption requirements by deactivating power consuming 
parts of its application or by lowering its performance to stay operational. Therefore the UICC application need to be 
informed before its selection about the available power supply of the terminal to react accordingly. 

4.13.2 Background (informative) 

4.1 3.2.1 Use case - generic situation 

A typical situation will be that on the UICC several applications (e.g. USIM, ISIM, WIM, toolkit applications etc.) are 
installed. If one or more applications need a value of power consumption higher than the minimum one specified in 
TS 102 221 [1], table 6.4 (but still within the range defined in TS 102 221 [1], table 6.3), then the application has to 
indicate in the response of a SELECT or STATUS command the power consumption value needed. If the terminal is 
not capable of delivering this power supply then a mechanism to inform the UICC is missing and therefore the 
application cannot work properly and no mobile communication is possible. 

4.1 3.2.2 Use case - USIM application with toolkit applications 

The most important application on an UICC within a 3G mobile phone is the USIM application necessary for mobile 
communication. Even if under normal circumstances this application requires a value of power consumption inside the 
range of TS 102 221 [1], table 6.4, typically additional toolkit applications associated with the USIM application are 
installed to provide additional services to the mobile phone user. Such toolkit applications could require an increase of 
the overall power consumption to a value higher than the guaranteed minimum supplied by the terminal (e.g. 
application using USSM for asymmetric cryptography). As the toolkit applications are not directly selected by the 
terminal, the USIM application would, in this case, have to request a higher power consumption during its selection. 

In a situation where the USIM would require a power consumption higher than the maximum value indicated by the 
terminal, the USIM application shall remain operational and has to provide basic network functionality. 

If the application running on the UICC can identify the maximum possible power supply delivered by the terminal then 
it may adjust its maximum power consumption inside of terminals with limited power supply by one of the following 
actions to guarantee its operation: 

a) It deactivates application parts consuming more power (e.g. toolkit application). 

b) It reduces its performance of power consuming parts (e.g. by dividing the CPU clock). 
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4.13.3 Requirements 
4.13.3.1 General Requirements 



Identifier 


Requirement 


REQ-7-13-01-01 


A mechanism shall be introduced that informs the UICC about the maximum 
power consumption supported by the terminal. 


REQ-7-13-01-02 


The power consumption indication mechanism shall be mandatory for a 
Release 7 terminal (or higher) able to provide more than the minimum power 
consumption. 


REQ-7-13-01-03 


The power consumption indication mechanism shall be optional for Release 7 
terminal (or higher) providing only the minimum power consumption (see note). 


REQ-7-13-01-04 


In the case where the power consumption indication mechanism is supported 
by the terminal, the UICC shall be informed about the maximum power 
consumption before the first application selection command. 





NOTE: It is recommended that Release 7 terminal with minimum power supply offer the power consumption 
indication mechanism. 



4.1 3.3.2 Backward compatibility requirements 



Identifier 



Requirement 



REQ-7-1 3-02-01 



The power consumption indication shall not generate backward compatibility issues with pre-release 7 
UlCCs and terminals. 



REQ-7-1 3-02-02 



A UICC capable of receiving this indication shall stay with the minimum power consumption if no 
indication is given by the terminal. 



4.13.4 Interaction with existing features (informative) 



(none) 



£75/ 



Release 7 



31 



ETSI TS 102 412 V7.3.0 (2006-03) 



Annex A (informative): 
Change history 



The table below indicates changes that have been incorporated into the present document since it was created by TC SCP. 
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